packages/ui/src/mosaic/organization/organization-profile-domains-section-remove.view.tsx (1)

63-78: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Consider surfacing an in-progress label while deleting.

Buttons are correctly disabled during isDeleting, but the "Remove domain" label never changes to indicate work is in progress. A small text swap (e.g. "Removing…") would improve clarity without changing behavior.

♻️ Optional tweak

               <Button
                 intent='destructive'
                 type='button'
                 disabled={isDeleting}
                 onClick={() => send({ type: 'CONFIRM' })}
               >
-                Remove domain
+                {isDeleting ? 'Removing…' : 'Remove domain'}
               </Button>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@packages/ui/src/mosaic/organization/organization-profile-domains-section-remove.view.tsx`
around lines 63 - 78, The deletion confirmation UI in
organization-profile-domains-section-remove.view.tsx keeps the Remove domain
button enabled state correct via isDeleting, but the label never reflects that
the action is underway. Update the Button rendered for the confirm action inside
the delete flow to swap its text based on isDeleting (for example, show an
in-progress label like “Removing…” while the machine is deleting, and “Remove
domain” otherwise), using the existing send and isDeleting state in this
component.

packages/ui/src/mosaic/organization/organization-profile-domains-section-add-verify.view.tsx (1)

70-252: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Repeated form/Actions structure across the four steps.

Each step (name/email/code/enrollment) duplicates the same <form onSubmit=...><Actions .../></form> shape with slightly different guards. This isn't a functional problem, but extracting a small StepForm wrapper that takes onSubmit, canSubmit, and children could reduce duplication and make future steps easier to add.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@packages/ui/src/mosaic/organization/organization-profile-domains-section-add-verify.view.tsx`
around lines 70 - 252, The four step blocks in the add/verify dialog repeat the
same form submission pattern around onSubmit and Actions, so extract a shared
StepForm wrapper in organization-profile-domains-section-add-verify.view.tsx to
centralize the form shell. Have the wrapper accept the submit handler, a
canSubmit flag, and children, then use it for the isNameStep, isEmailStep,
isCodeStep, and isEnrollmentStep sections while keeping each step’s specific
fields and guards intact.

packages/ui/src/mosaic/organization/__tests__/organization-profile-domains-section-enrollment.machine.test.ts (1)

1-117: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Missing coverage for the stale deletePending edge case.

Consider adding a test that: checks deletePending, switches to a non-manual_invitation mode, switches back to the committed mode, and asserts SUBMIT is not enabled (or that deletePending is reset). This would have caught the issue flagged in organization-profile-domains-section-enrollment.machine.ts.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@packages/ui/src/mosaic/organization/__tests__/organization-profile-domains-section-enrollment.machine.test.ts`
around lines 1 - 117, There is no test covering the stale deletePending state
when the draft mode is changed away from and then back to the committed mode,
which can leave SUBMIT incorrectly enabled. Add a case in
organizationProfileDomainsSectionEnrollmentMachine tests that opens the machine,
toggles deletePending, selects a non-manual_invitation mode, switches back to
the committed mode, and then verifies either actor.can({ type: 'SUBMIT' }) is
false or the draft deletePending state is reset. Use the existing open helper
and the SELECT_MODE, TOGGLE_DELETE_PENDING, and SUBMIT events to keep the test
aligned with the machine behavior.

packages/ui/src/mosaic/organization/organization-profile-domains-section.view.tsx (1)

117-148: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add accessible names to per-row action buttons.

Manage/Verify/Remove render identically across every row; a screen-reader user tabbing through the list only hears the generic label with no domain context. Consider aria-label={Remove ${domain.name}} (and similarly for Manage/Verify).

♿ Proposed fix

           <Button
             variant='ghost'
             size='sm'
             intent='destructive'
             type='button'
+            aria-label={`Remove ${domain.name}`}
             onClick={() => onRemove(domain)}
           >
             Remove
           </Button>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@packages/ui/src/mosaic/organization/organization-profile-domains-section.view.tsx`
around lines 117 - 148, The per-row action buttons in the organization profile
domains section use identical visible labels, so add accessible names that
include the domain context. Update the buttons rendered in the
`organization-profile-domains-section` row actions so `Manage`, `Verify`, and
`Remove` each get an `aria-label` that includes `domain.name` (for example,
through the existing `onManage`, `onVerify`, and `onRemove` button handlers),
while keeping the visible button text unchanged.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes